Many mobile devices such as tablets and smart phones, as well as embedded devices, make use of an operating system stored within non-volatile memory, such as Flash memory.
Increasingly, it is becoming seen as good practice to encrypt mobile or embedded devices that contain even vaguely sensitive information. Indeed, loss of data is seen as being very bad from both publicity and a legal perspectives (particularly with regard to data protection legislation) and many companies are only slowly becoming aware of how vulnerable the data is that their employees are carrying around on tablets etc.
While a password protected boot sequence or lock screen is better than nothing on such devices, it does not stop a determined attacker. Generally, it is desirable for the data itself to be encrypted.
Common approaches to implementing encryption on such devices require that part of the operating system remains un-encrypted. The un-encrypted portion of the operating system is loaded by a bootloader during the boot process and executes prior to user authentication being performed. Successful user authentication allows an encryption key to be recovered and the encrypted portion of the operating system can then be loaded. This approach typically simplifies the engineering task, as components of the operating system are available to undertake user authentication tasks, including interacting with device specific hardware such as a touch screen device. However the approach has a significant disadvantage from a security perspective, as a portion of the operating system is still unencrypted. In such a situation, an attacker could tamper with the unencrypted portion of the operating system, potentially by exploiting a known vulnerability within the system, allowing user credentials to be subsequently captured and rendering the entire system vulnerable.
In order to avoid security exploits, it is desirable that the whole operating system of such devices is encrypted.
During start-up of a general purpose PC, a series of steps are performed, commonly in the following order:
a) When the PC is powered up, the Basic Input Output System (BIOS) is executed. The BIOS is typically firmware stored in read only memory, ROM, of the PC;
b) The BIOS may perform steps such as a power-on-self-test (POST) to check memory and other hardware components of the PC, it may also offer the user access to a setup menu to set hardware parameters;
c) A bootloader is then executed. In general purpose PCs, the bootloader is typically a relatively small program stored in ROM, along with the bare minimum of data needed to access the non-volatile devices from which the operating system programs and data may be loaded into RAM. Bootloaders may chain load functionality such that the initial code executed is simple but each step in the chain causes more complex functionality to the loaded.
The approach used in conventional disk-based computer systems for whole operating system encryption is to introduce a pre-operating system that utilises interrupts in the computer system's BIOS during bootloader execution. The pre-operating system facilitates authentication and key recovery in an environment that is separate to the encrypted operating system. Once the key has been recovered, all BIOS level input and output operations (to which higher level disk I/O are eventually decomposed into) are intercepted by a driver, such that encryption and decryption operations are appropriately included for disk access. In this manner, the disk holding the operating system can be fully encrypted. Only if authentication by the pre-operating system is successful is key recovery possible and as a result, access of the encrypted disk (both operating system and data) is only possible upon authentication.
Clearly, this significantly increases security as the authentication components are separated from the data and operating system. Even if the authentication system becomes compromised and an exploit is found to access the memory or disk on which it is stored, the data and operating system are encrypted and held elsewhere.
While whole disk encryption is well established in general purpose PCs such as desktops and laptops, many mobile device types do not lend themselves well to encryption and particularly not to that of the whole operating system. For example, mobile devices that make use of non-volatile Flash memory for operating system storage typically do not have BIOS interrupts that may be used to facilitate pre-operating system encryption. This is in contrast to encryption products designed for disk based systems that typically use BIOS interrupts or a similar mechanism, to intercept disk activity.
Unlike in general purpose PCs, in mobile devices the bootloader is often specific to the hardware configuration of the device. This is because it is required to perform specific hardware initiation tasks before the operating system is loaded. The bootloader component typically resides in non-volatile memory, and is effectively a component of the system's firmware.
In the case of flash-based systems, the approach taken to whole disk encryption in general purpose PCs is not possible due to architecture differences. In particular, within the typical architecture of flash-based devices, the initial operating system loader does not have hardware interrupts available for flash memory access. This prevents the same approach being taken for input and output interception using the driver model. Furthermore, the operating system is typically interconnected with the lower level functions in flash based systems. As a result, separation of the two so as to encrypt one but not the other is not straightforward. For example, if the non-volatile memory including the firmware is encrypted then the hardware functionality such as a touch screen interface would not be accessible to the pre-operating system environment as it would be implemented in the firmware. Consequently, there would be no input mechanism available to provide the pre-operating system environment.